木桶理论说明，系统整体可用性取决于最脆弱、性能最低的组件。消息队列作为关键中间件，其高可用、高性能与选型直接影响系统稳定性。本文整合三大主题：消息队列的高可用设计（以 Kafka 副本机制为例）、Kafka 的高性能原理、以及 RocketMQ 的架构特性与组件选型。
分布式系统的高可用依赖副本技术：引入副本使系统更好扩展，节点宕机时可快速替换，提升可靠性、防止数据丢失。消息队列在系统中承担数据存储和数据传输两种功能，因此其高可用设计比数据库、文件索引等持久化存储更复杂。面试中若被问到"MQ 如何高可用"，可从副本、集群、一致性三个方向展开。
Broker 与 Partition 的关系：Broker 是 Kafka 服务器节点，集群由多个 Broker 组成；Topic 是逻辑概念（消息分类），一个 Topic 被分散到多个 Partition（物理概念，对应磁盘文件）——这是 Kafka 可扩展性的基础。
关键约束：Kafka 保证消息在 Partition 内部有序，Partition 连续存储、不跨 Broker/磁盘；Partition 可细分为一个或多个 Segment（index 索引文件 + log 数据文件）。
元数据管理演进：早期 Kafka 依赖 ZooKeeper 管理 Broker 注册与 Controller 选举；2.8 引入 KRaft（预览），3.3 正式 GA，4.0 起完全移除 ZooKeeper，元数据由 KRaft 控制面的 Raft 元数据日志管理。
副本间的数据同步：通过 replication-factor（副本因子）配置分区副本数。同一条 Partition 的多个副本分工不同：
Fetch Request 批量拉取 Leader 数据进行同步（由独立线程 ReplicaFetcherThread 完成）。副本分配原则：一个 Topic 的 Partition 数量大于 Broker 数量，使 Partition 尽量均匀分配；同一个分区的所有副本分散到不同 Broker，否则副本失去意义（同机故障会同时挂掉主从）。
Leader 选举与 ISR：引入副本后，Leader 宕机需要重新选举。Kafka 的同步核心是 ISR（In-Sync Replicas，副本同步队列）：
replica.lag.time.max.ms（Follower 落后 Leader 的允许时长，超时即被移出 ISR；Kafka 2.5 起默认 30s，更早版本默认 10s）；生产端的 ACK 级别：acks=0（不等确认，可能丢）、acks=1（Leader 落盘即返回，Leader 挂且未同步时丢）、acks=all（等 ISR 全部确认，配合 min.insync.replicas 指定最小同步副本数——两者组合才是"不丢"的完整承诺：ISR 收缩到小于 min.insync.replicas 时拒绝写入）。此外，消费位移存储在内部 Topic __consumer_offsets 中。
选举策略：若 Leader 宕机，从 ISR 列表选新 Leader。若 ISR 为空：抛异常（NoReplicaOnlineException，保证一致性，分区不可用）或从其他副本选 Leader（保证可用性，可能丢数据）。
所有副本都挂掉怎么办：极端情况下一个分区的所有副本都宕机，可配置两种恢复策略：
方案一重一致性、方案二重可用性，需按业务场景选择。
副本与投递语义的权衡：Leader 等待所有 Follower 同步后才 ACK 会大幅降低吞吐，因此 Kafka 引入 ISR 副本分层管理：Leader 只需等待 ISR 中副本同步即可返回 ACK，在"不丢数据"与"高吞吐"之间取得平衡——这也是 ISR 设计的核心动机。
Kafka 消息存储在磁盘上，却能做到高速读写，关键在于顺序写而非随机写：消息队列主要提供生产与消费操作，不涉及数据 CRUD；Kafka 写入磁盘时采用顺序追加（append），避免了机械硬盘最耗时的磁盘寻址操作。在单个分区内顺序写，即使是普通机械磁盘也能获得很高吞吐。
原理：机械硬盘随机写因寻址（磁头移动）很慢，顺序写则磁头连续移动，几乎可以达到磁盘接口极限速率。
写入文件系统的数据先进入操作系统 Page Cache，尚未落到物理磁盘。刷盘（Flush）分两种：依赖 OS 定时刷盘（异步，性能高但宕机可能丢数据）与同步刷盘（fsync，可靠性高但性能低）。Kafka 默认采用异步刷盘——不等数据落盘就返回投递 ACK，从而提升吞吐、降低延迟（牺牲一定可靠性，可通过副本机制补偿）。
零拷贝是操作系统文件读写的一种优化技术——减少不必要的用户态/内核态拷贝次数。
传统 IO 的多次拷贝：用户进程运行在用户空间，不能直接操作内核缓冲。传统 IO 流程：磁盘 → 内核缓冲区 → 用户空间（应用处理）→ 内核缓冲区 → Socket。数据在"内核态 ↔ 用户态"间多次拷贝并多次上下文切换，性能损耗大。
Sendfile：Kafka 依赖 Linux 的 sendfile 系统调用：数据在内核缓冲区直接完成输入输出，不经过用户空间，避免重复拷贝、减少上下文切换。Kafka 把消息存放在单独文件中，投递时直接通过 sendfile 发送文件（Apache/Nginx 等也应用此技术）。
MMAP（内存映射）：Kafka 运行在 JVM 上，但不把所有数据操作放在堆内存（会加大 GC 压力）。通过 **Memory Mapped Files（内存映射）**将文件直接映射到用户态内存空间，对文件操作不再 read/write，而是直接对内存地址操作，省去"用户空间 ↔ 内核空间"的拷贝开销。
| 技术 | 思路 | 适用 |
|---|---|---|
| Sendfile | 数据在内核态直接传输到 Socket | 文件 → 网络的高效传输 |
| MMAP | 文件映射到用户内存直接操作 | 频繁小数据读写的场景 |
零拷贝技术在其他 IO 场景同样有应用，如 Netty 的网络 IO 优化。Linux 中"一切皆文件"，Kafka 关注文件 IO、Netty 关注网络 IO，但底层优化思路相通。
Kafka 高性能四大利器：磁盘顺序读写、异步刷盘、批量 + 压缩、零拷贝。顺序写规避机械硬盘寻址延迟；异步刷盘提升吞吐（以可靠性换性能，用副本补偿）；批量 + 压缩减少网络 IO；零拷贝（Sendfile/MMAP）减少内核态/用户态拷贝与上下文切换。
RocketMQ 由阿里巴巴开源，提供低延时、高可靠的消息发布订阅服务。核心组件：
Tag：Topic 的二级分类：RocketMQ 支持 Tag（子主题），对 Topic 进一步细分，使订阅更灵活。例如 Order-Topic 下的 Order-Create-Message（创建）、Order-Pay-Message（支付）等 Tag。
事务消息（实现分布式最终一致）：RocketMQ 的事务消息支持类似 XA 的分布式事务，达到最终一致。核心引入 Half Message（半事务消息）：消息先处于"未完成"的中间状态，通过类似两阶段的流程，结合本地事务执行与消息确认/回查，实现分布式事务的最终一致。典型场景：下单后扣款。
延迟消息：支持按指定延迟时间投递，适用于订单超时未支付自动关闭等场景。4.x 仅支持 18 个固定延迟级别（1s/5s/10s/30s/1m/...，由 broker 端 messageDelayLevel 配置）；5.0 起 Timer Wheel（定时轮）支持任意精度延迟。
顺序消息：支持全局/局部顺序消息（配合队列与分区键），满足严格有序消费。
消息过滤：支持 Tag 二级过滤（Broker 端初筛 + 消费端精确匹配），还支持 SQL92 表达式按消息属性过滤。
高可靠：支持同步刷盘、主从复制等机制，写入磁盘成功才返回发送成功，保证消息不丢。
Binlog 分发：Canal + RocketMQ：业务数据分散在数据库、文件索引（如 ES）、缓存等多个存储中，需保证一致性，典型方案是基于 Binlog 的数据同步：
分布式一致性：事务消息用于解决"跨系统的分布式事务"，如电商下单、扣款、支付联动等。
| 组件 | 语言 | 特点 | 适用场景 |
|---|---|---|---|
| Kafka | Scala | 高吞吐、持久化、分布式 | 大数据、日志采集、监控、流处理 |
| RocketMQ | Java | 高可靠、顺序/事务消息、经过双十一考验 | 电商等复杂业务、需可靠投递 |
| RabbitMQ | Erlang | 功能全面、多协议、优先级队列 | 企业级应用、复杂路由、中小规模 |
Kafka：LinkedIn 开源，通过磁盘顺序读写、零拷贝实现极高吞吐；消息持久化、适合数据埋点、日志收集与计算、监控与大数据分析。
RocketMQ：阿里开源（Java），高可靠（同步刷盘）、强一致，适合电商等对一致性、可靠性要求高的复杂业务。
RabbitMQ：Erlang 编写，支持 AMQP 等多种协议，路由模型灵活；局限：不适合超大数据量，消息堆积时性能下降明显；适合企业级应用、后台数据同步。
在真实系统中常组合使用多款 MQ 以发挥各自优势。以电商系统为例：
Topic → Partition → Segment 分层提供可扩展性，Partition 内部有序；副本分 Leader（读写）/Follower（备份）；ISR 保证只有已同步副本可当选 Leader，兼顾一致性与吞吐；